home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Magnum One
/
Magnum One (Mid-American Digital) (Disc Manufacturing).iso
/
d20
/
xrdor200.arc
/
_NEW_IN_.200
next >
Wrap
Text File
|
1991-05-04
|
12KB
|
204 lines
XRS "eXpress Response System" <tm> Door version 2.00 changes:
(since "RAX/QMX/SeX" version 1.40)
-1) This version is compiled with the new Borland C++ 2.0 - everything
_should_ work the same (hopefully not famous last words!)...
0) No more "RAX/QMX/SeX" - it's always "XRS Door" for consistency on
different boards and to avoid confusion when "atypical" software
combinations are used. XRSDoor still runs equally well any any
(currently available) "Hudson-style" message database, which includes
RemoteAccess, QuickBBS or SuperBBS at this writing.
1) XRS Door supports "UserRequests" which include both an AreaFix-like
capability and the ability to "psuedo-FileRequest" from the BBS (i.e.
automate the download of files by sending a message). Please see the
separate "REQUESTS.DOC" for a full description.
* * * * * * * * * * * * * * * * * * * * * * * * * *
WARNING! IN ORDER TO SUPPORT THIS, XRS MUST HAVE
A "PRIVATE" SUBDIRECTORY FOR EACH NODE YOU HAVE,
TO PROCESS INBOUND MAIL AND "CLEANSE" THE MAIL OF
MESSAGES ADDRESSED TO 'XRS' (the UserRequests).
FAILURE TO HAVE AN EMPTY SUBDIRECTORY AT STARTUP
OF UPLOADS TO XRS DOOR COULD POTENTIALLY GO INTO
A LOOP TRYING TO PROCESS SOMETHING THAT IT THINKS
IS MAIL. XRS DOOR ONLY EXTRACTS *.PKT FILES FROM
USER-UPLOADED MAILBAGS (OR WILL USE "NAKED" *.PKT
FILES FROM NON-MSDOS USERS), AND NUKES THE REST,
SO THERE IS NO WAY FOR A "MAIL BOMB" TO GET BY!
* * * * * * * * * * * * * * * * * * * * * * * * * *
XRS now leaves behind only *.PKT files when it is through - see item #
6 for important information on online mail tossing, netmail accounting,
etc using "Mk/Xrs"! (this allows you to support RIME and other network
software other than FidoNet, too)
2) If XRS Door finds a record marked for deletion by XRUserEd, it reuses
the "slot" for the next new user, using the same point number the old
user had previously been assigned. XRS Door shows the SysOp whether or
not a record marked for deletion is reassigned on the local console,
but does not display that information on the remote screen. (it also
says "No user record marked for deletion found" if it can't find one)
As a byproduct of this, if a user marked for deletion happens to log in
and use the program before his record gets reallocated, the "Delete"
flag is cleared, so he doesn't lose his identity (point #). Note that
in XRUserEd, the users are arranged by number - in the actual file, the
users are in alphabetic ascending order for quick binary search (so the
user that looks like the 'first' marked for deletion in XRUserEd is not
necessarilly the first one in the file). It replace the lowest one
(alphabetically) marked for deletion, if any. (the lowest alphabetic
name in XRUserEd is the one which is highlighted when you start) Note
that a new completely functional XRUserEd v 1.01 is included, which also
allows you to mangle the users' selections, protocol, packer, etc.
XRUserEd still expects to find "AREAS.BBS" in the current subdirectory
like QuickBBS used to (and I hope still does!), but if it is not there,
you can specify where it is located on the command-line: "XRUserEd Msg".
3) XRS Door allows a limit of up to 5000 messages. Normally only 995 are
sent, but using the "set maximum message count limit" <O>ption toggle,
you can set either a lower _or_ higher count up to the limit imposed by
the amount of time you have available. Having more than 995 requires
XRS version 4.11 or later! The SysOp must allow more than 995 messages
which is still the "MaxLimit" default. (i.e. put "LIMIT 2000" into the
QMXSETUP.CFG file, up to a maximum of "LIMIT 5000" if you wish) XRSDoor
*still* takes into account the time remaining when computing the actual
number of messages a user at a specific baud rate can actually retrieve!
4) XRS Door only updates LASTREAD.BBS for areas which are selected.
5) XRS Door displays remaining time available in each header display.
6) Mark May's "Mk/Xrs" program can be used to completely automate all
inbound mail processing including netmail accounting and tossing mail
directly into the BBS message databases without using your normal echo
mailmangler. MKXRS103.ZIP is the current released version - it works
equally well on any single or multi-line system, but if you have two
or more nodes, you should have separate "inbound" XRS-mail areas. You
can call MKXRS automatically after each incoming mailbag is inspected
for UserRequests by placing "MKXRS" into your QMXSETUP.CFG file.
7) Since XRS Door supports file-requests, it is unlikely that most SysOps
will want to continue "*!" free time. A new QMXSETUP.CFG parameter
allows you to give users 'x' minutes of free time - "FreeTime 20" will
add 20 minutes to the available time in the door. NOTE HOWEVER, that
you most likely still need to add "*!" to the command-line on the menu,
or the BBS software is liable to terminate the door when time would have
normally run out! That way, the BBS thinks the user has unlimited time,
but actually, they get no more than the remaining time (plus "Freetime"
extra minutes if you specify any).
8) Setting the "CRASH" bit using XRUserEd 1.01 allows you to specify any
user having the ability to send netmail with the CRASH attribute on. If
you are the SysOp of a QuickBBS system, set the flag on for yourself.
Until I have final specs for the new QuickBBS layouts, I will not change
the program... Version 1.01 of XRUserEd (included in the archive) also
allows you to set any of the other bits available. ("Prepack mailbags"
is shown and toggles, but a program to auto-pack is not available yet)
9) You can force users to read a certain area on your board by placing a
new parameter "FORCE x" where 'x' = the area *number* you want to be
required reading. Note that RaQmSeX doesn't tell the user it is forced
nor display it as part of his list (unless he already selected it), nor
will turning the area off (as many times as he wants <grin>...) work.
There can be up to ten of these in your config file. IMPORTANT NOTE:
IF YOU TURN ON A CONFERENCE WITH "FORCE" ALL READ SECURITY IS IGNORED!
(but if the user doesn't qualify for write access, they cannot reply)
Remember - this takes an area *number* as the argument - not a name.
10) The same way you can "Force xxx" (where 'xxx' = area number) areas
on, you can "Lockout xxx" up to ten areas.
11) The file CURR_VER.XRS (which accepts up to 64 characters) is displayed
for all users so they know what the latest version is (of XRS). (sample
CURR_VER.XRS included) For RA systems, a single copy of this file should
be kept in your "System" subdirectory.
12) The expected filename for incoming mailbag uploads is displayed, so a
user that calls multiple XRS-capable systems knows which file to upload.
13) XRS Door handles <CTRL_C> properly, in all cases just exits back to the
BBS. (previously, depending on what was happening at the time, it was
possible to lock up the system!) You can teminate XRS Door safely using
<CTRL_C> or <CTRL_K> either locally or across the modem. XRSDoor places
a 'funny' message into the log about the "User Broke Me!" if this happens.
14) If "SysOpOut xxx" is in effect and an XORIGIN.XRS file is detected, it
is automatically copied to the 'xxx' sub-directory.
15) The routines used to write to the logfile were greatly optimized.
16) A problem which caused XRS to display confusing <J>ump summaries which
didn't match the actual messages is fixed (if there is garbage in the BBS
message headers, any <CR> & <LF> characters are filtered out).
17) "Show Pids" in QMXSETUP.CFG puts any ^aPID: lines found into mailbags.
18) XRS Door will auto-bag mail if a valid DORINFO1.DEF & EXITINFO.BBS are
found and the environment variable "RQS" = 'AUTO'. This allows the SysOp
to automatically pack his own mail daily, for example (would not work too
well with "SysOpOut"!). Soon, XRUserEd and another program will allow
you to designate users to be pre-packed, as well. XRSDoor suppresses the
display of most things when in auto-pack mode, and automatically knows to
switch to "Local" mode, regardless of what might be in the DORINFO1.DEF
file. Note that if you setup a batch file to 'autobag' your mail each
night, you *must* save the updated EXITINFO.BBS each time, since you will
not be keeping a record of the updated "HighMsgRead". Note also that if
an autobag session packs the maximum amount of mail allowed, it will just
start at that point the next time it is run, also if it finds itself in
autobag mode and either the "High Message" < "Next to Read" or there are
no new messages after the header scan, XRSDoor will exit immediately. A
sample batch file "AUTO_BAG.BAT" is included - you will _HAVE_ to modify
it before it can be used. You may want to implement some sort of rename
by date function to save each days' mail under a unique name.
19) Swaps to LIM or Disk (current drive and sub-directory using the filename
"SWAP$RQS.!!!") if "SWAP" is in your QMXSETUP.CFG file. XRS swaps the
(less than) 116K memory it uses minus a 4K reloader 'stub' on disk if 112K
of LIM/EMS memory is not found. Swapping is used for all external program
calls including DSZ.COM, MKXRS.EXE and archival programs. Swapping to
LIM/EMS is instantaneous, disk swapping is relative to disk performance
but hardly noticable even on the slowest hard drive, since XRSDoor doesn't
have a large 'footprint'. Allowing "Swap" is definitely most useful for
multi-node setups running under DesqView, for example.
20) If you do not want XRSDoor to swap to LIM/EMS (use disk only), put the
"No EMS" parameter into QMXSETUP.CFG to avoid LIM/EMS swapping. This is
useful only in combination with "Swap". (note: if you do not have any EMS
memory, this parameter is not needed - XRSDoor will not try LIM/EMS...)
The only reason I can think of that you might need this is if your LIM/EMS
is not working properly, or you are running a multi-tasker and don't want
XRSDoor to tie up that memory even temporarilly. If you have LIM/EMS but
do not have enough free, XRSDoor will swap to disk instead automatically.
21) XRSDoor recognizes anything except '0' in DORINFO1.DEF as being color
graphics mode (no need to kludge the file with another utility). Avatar
output calls will be added to 2.01, but for now, XRSDoor assumes the user
has an ANSI "fallback", since Avatar is usually implemented as a superset
of ANSI (Q-Modem works this way, and I suspect many other do, as well).
22) If the user input times out or carrier is lost when waiting at the
"Update High Message Number?" prompt, the pointers are updated anyway.
23) When a user timeout (three minutes with no response) occurs, the colors
are reset to light grey (dim white) on black.
24) The somewhat confusing "Yes/No/Logoff" prompt is replaced by a mini-menu
that is more explanatory. Logoff is now "Quick pack, update & logoff" (or
"Quick pack and update pointers" if you are local, since dropping carrier
does not log you off locally).
25) If no new messages are found, you go directly to the main menu instead
of through the "Yes/No/Quick" sub-menu, since "Yes" or "Quick" here would
simply quit back to the BBS anyway (because no mail would be found).
26) The "Quick Pack" option works for local users, but is does not display
the ten-second countdown, since dropping carrier has no effect in local
mode (you go back to the BBS immediately either way locally).
27) The high-bit graphics characters '>>' and '<<' around threads are just
single '>' and '<' (non-graphics) charcaters, to eliminate problems for
non-DOS machines.
28) LHA is used in place of LHARC. If you don't already have the new LHA
(formerly LHArc) version 2.10 (or later) - you should! It packs tighter
than PKZip and is faster than previous versions.